1. Field of the Invention
The present invention relates to service creation apparatus for a communications network, and finds particular application in intelligent networks.
2. Related Art
As communications networks have developed, there has been a major increase in the number and variety of services which a network operator can deploy. It is a key commercial issue for network operators to be able to create and deploy new services quickly and efficiently. The intelligent network form of architecture, wherein intelligence is provided at a variety of points in or associated with a communications network rather than primarily at a switch or exchange as has been the case in the past, has been developed at least partly to give the network operator the facility to provide new services with speed and flexibility.
A key principle in intelligent networks (IN) is the separation of software which controls basic switch functionality, such as setting up switch paths, from the software that controls call progression. Referring to FIG. 23, this has been achieved in known INs by enabling network exchanges 230 to recognise calls which require modified call progression and to suspend ordinary call processing. The decision to suspend call processing is based on the meeting of pre-specified trigger criteria, for example dialling digits, line condition or time of day, at certain points during the call. This can be described as xe2x80x9cservice switching point (SSP)xe2x80x9d functionality being provided at the network exchange 230.
On recognising a call needing an IN-based service, the SSP functionality refers to a service control point (SCP) 231 and call progression is thereafter controlled by intelligence outside the basic network exchange 230 to provide whatever service the call required.
An aspect of an intelligent network architecture which is particularly relevant to the provision and modification of services is the service creation and deployment system. Attributes that are particularly attractive in an IN to accelerate the creation of new services are:
i Functional separationxe2x80x94this is the separation of basic core functions of real time call switching from the customer and service specific aspects, so that the latter can be changed more easily, which is mentioned above.
ii Portable software environmentxe2x80x94enabling services to be developed once and then run on SCPs 231 provided by different suppliers.
iii Generic building blocksxe2x80x94building services from common modules allows considerable reuse and hence speed of development.
iv Service logic programs (SLPs)xe2x80x94a simple language for specifying the linkages between building blocks. SLPs are usually produced by service creation tools.
v Graphical service creation toolsxe2x80x94these tools enable services to be rapidly created, by xe2x80x98on screenxe2x80x99 manipulation of icons which represent the generic building blocks.
vi Service and network simulatorsxe2x80x94when a service has been created, it can be simulated to check its functionality, performance, cost, etc.
vii On-line deploymentxe2x80x94when a service is ready for deployment it can be electronically sent to the network and the appropriate management systems, from the service creation tool.
Services are created, in a known type of service creation environment 232, from the generic building blocks by specifying the sequences of these blocks and any conditional linkages between the blocks. This specification is frequently known as a script or service logic program (SLP) and is usually generated by a service creation tool. When this SLP is deployed into the network it needs to be xe2x80x98executedxe2x80x99. This is done in a Service Logic Execution Environment (SLEE) which often sits in the SCP 231. The module for doing this execution itself is often called a Service Logic Interpreter (SLI) because many IN implementations use an interpreted language for their SLPs. It does not have to be an interpreter however and can more generically be called for instance a Service Engine. This might support interpreted or compiled, and possibly other forms of SLP.
Together with the Service Creation tools themselves, the use of re-usable generic building blocks is important in service creation. In the general world of computing much work has been done on trying to achieve significant software reuse because the benefits are significant. For example, reusing a program three times effectively triples productivity and furthermore on the second and subsequent time it is used, the lead time can be virtually zero.
Despite these benefits, general software reuse is still rare because it is difficult to realise. However, within the fairly closed domain of the SCP, where the discrete operations of the underlying network are well understood, it is possible to build generic pieces of software to drive these underlying operations. These are the building blocks which can be called in many different sequences to provide the diverse range of IN services.
A typical building block might be xe2x80x9ctime of day routingxe2x80x9d. This building block would check the data in a user""s profile which may state that after 6:00 pm calls to a particular number are diverted to a night-watchman. The xe2x80x9ctime of day routingxe2x80x9d building block would then check the current time and route the call appropriately.
SLPs can be delivered to the SLEE via a Service Management System (SMS) 233. This is generally responsible for service management, deployment, and provisioning of customers and updating customer specific data held on the SCP 231 and the Service Data Point (SDP) 234.
It is advantageous that service creation can be carried out not only by a network service provider but also by subscribers or users themselves. Service Creation technology enabling different entities to develop or modify services is described in the publication xe2x80x9cService Creation Technologies for the Intelligent Networkxe2x80x9d by M J Morgan et al, published in the ATandT Technical Journal Volume 70, Summer 1991, No. 3/4, New York U.S.
In embodiments of the present invention, there is provided a service creation and provision system for a communications network in which communications services can be created or modified by screen-based manipulation of ordered sequences of units of code, the system providing a service by running such an ordered sequence of units of code in accordance with an execute graph, wherein the system comprises:
i) an interface to stored units of code;
ii) means to select a set of units of code from those stored;
iii) means to create or modify an edit graph, the edit graph determining at least in part the ordered sequence associated with a set of units of code for the provision of a communications service; and
iv) means to associate an edit graph with visual information for use by a user on a graphical user interface in editing or modifying the edit graph to produce an execute graph, and means to supply the edit graph together with the visual information to the graphical user interface;
wherein the means to supply the edit graph together with visual information is adapted to supply at least one edit graph without visual information such that an execute graph can be produced from the edit graph without the edit graph being visible, or being only partially visible, to the user.
An execute graph may then be used by a service engine of the system in running a service logic program in the provision of a service.
Embodiments of the present invention may be particularly useful in a multi-level service creation environment, such as a known type of three level service creation environment. Each level provides different functionality and is for the use of a different set of users, for instance for the network provider for installing units of code to the network, for the service provider to create and modify services, and for the customer to create, modify or instantiate actual services for their users.
These levels may be designated for instance SCE1, SCE2 and SCE3. The use of separate levels allows access to the service creation system to be kept functionally separate for users having different interests in the network. Hence, features which have to be installed at the network element level for a selected service to be available can be created in SCE1. Marketable service features, which give a view of features in that they encapsulate call handling logic thereof together with support and management descriptions of the feature, can be created in SCE2. Service packages, which permit collection of marketable service features to meet requirements of a service together with service-specific support and management information, can be created in either of SCE2 or SCE3. Profiles, which list the features relevant to a service for a user and provide data slots for the data necessary to each feature, can be provisioned and modified in SCE3.
In preferred embodiments of the present invention, therefore, each of the levels is provided with means to generate different respective types of software entity, a first of said levels having means to generate service application features which comprise code objects which can be deployed in elements of the network by means of a service distribution system, and a second of said levels having means to generate marketable service features, these comprising call-handling logic of a service application feature encapsulated with support and management descriptions for that feature.
The second of the levels may advantageously have means to store and output service packages, these being software entities having an association function for identifying and associating marketable service features with specific services available by means of the communications network.
A third of the levels may also have means to generate service packages, and means to generate or modify profiles, a profile comprising a list of one or more features that a user needs in selecting a service of said network, and means to store data relevant to each feature such that the feature can operate successfully in the context of the selected service.
A further advantage of a multi-level system of this type is the variation in control mechanisms which can be provided. For instance, control can be exercised at SCE2 of facilities, mechanisms or the like available to users operating at SCE3. This is where embodiments of the present invention have particular application in that edit graphs can be created or modified at SCE2 and supplied to SCE3 for use by the customer in generating execute graphs. By hiding selected aspects, even all, of an edit graph, it is possible to give the customer wide apparent latitude in generating an execute graph while still constraining them by use of a hidden or partially hidden edit graph which prevents them from generating and then running an untested version of a communications service.